fix: remove the per-call struct format strings from the response parse path - #286

Base branch: modernize/python-310-floor (#278). Review that pull request
first. The diff here is incremental, and it is nine lines.

What changed

bmemcached/protocol.py gains a module-level FLAGS_UNPACKER = struct.Struct('!L').
get and get_multi use it to read the 4 byte flags field, then slice the
rest of the body. Neither builds a format string any more.

The bytes() copy in _read_socket stays. The reason is below, with numbers.

Why

Commit 72d2aaf precompiled the request packers, but that work covered the send
path only. The receive path still built a format string on every call:

struct.unpack('!L%ds' % (bodylen - 4), ...)                      # get
struct.unpack('!L%ds%ds' % (keylen, bodylen - keylen - 4), ...)  # get_multi

CPython caches compiled struct formats in an LRU cache, 100 entries by
default. Because these formats embed the per-call value length, a workload
with more than 100 distinct value sizes evicts entries and recompiles on every
call. This is the same pattern 72d2aaf removed on the send side.

A struct.Struct for '!L%ds' % n is specific to one length n, so
precompiling one per length does not help. A fixed-format read plus a slice
compiles nothing at all.

Verification

nix develop --command bash -c 'pytest -q'

Result: 261 passed. This matches the baseline on main.

nix develop --command bash -c 'flake8'

Result: 0 errors.

Benchmark

The benchmark runs the parse step only. No socket and no server are involved,
because the change is about format compilation. Python 3.12, timeit.

The gain is largest past the cache, as expected. It is still real inside the
cache, because a % format and a lookup cost more than a slice.

The _read_socket copy: measured, and kept

The issue asked for a measurement, not a theory. Here it is.

The copy is real. bytes(bytearray) costs 0.073 us at 64 bytes, 0.111 us at
1 KB, 1.80 us at 16 KB, and 17.4 us at 256 KB. At large value sizes it
dominates the parse step this pull request just made faster.

It still stays, because removing it changes public return types. A bytearray
slice is a bytearray, not bytes:

• deserialize returns the raw buffer for a value carrying the binary flag.
  get would return a bytearray in place of bytes.
• get_multi uses the response key as a dict key. A bytearray is
  unhashable, so this raises TypeError.
• stats() tests isinstance(key, bytes) and would stop decoding the key. It
  would then use an unhashable bytearray as a dict key.
• The error paths format extra_content into an exception message. The text
  changes from b'...' to bytearray(b'...').

Each of those needs its own bytes() call. That puts the copy back for the
binary path and widens the change well past this issue. The acceptance
criteria allow the copy to stay with a stated reason, so it stays.

The copy is worth its own issue, together with a decision about whether
returning bytes for binary values is a contract this project wants to keep.
I have not opened that issue, because the answer is a design call for you, not
a defect. Say the word and I will open it.

Risks

A reviewer must check two points.

1. The slice arithmetic must match the old format strings. For get, the
   old format read 4 bytes of flags then bodylen - 4 bytes of value, so the
   value is extra_content[4:]. For get_multi, the old format read 4 bytes
   of flags, then keylen bytes of key, then bodylen - keylen - 4 bytes of
   value, so the key is extra_content[4:4 + keylen] and the value is
   extra_content[4 + keylen:]. extra_content is exactly bodylen bytes
   long, which is what makes the open-ended slices correct.
2. Return types are unchanged. _read_socket still returns bytes, so
   every slice is bytes, exactly as struct.unpack produced before. This is
   the direct consequence of keeping the copy.

struct.unpack raised struct.error on a body whose length did not match the
header. A slice does not. A short body now yields a short value in place of an
exception. No test covered that path, and the header check that #273 adds
catches the desynchronized-stream case that produces it.

Closes #276